this is exactly the change @citrus-it suggested here to fix #8176. i've mostly just been convincing myself i understand what exactly this changes.

my understanding is: the broad strokes of #8092 included always creating an incorporation.p5p (... package archive ...? i've had a very hard time learning the appropriate terms here), then using that to constrain the available packages. pinning is just using the incorporation.p5p produced at release-packaging-time instead of generating a fresh one. given a fresh one, notionally it should be the latest versions of all packages, and not actually imposing a constraint.

the issue then is: pkg list -g ... implies -a,

           -g path_or_uri
                   Use the specified package repository or archive as the
                   source of package data for the operation.  Repositories
                   that require a client SSL certificate cannot be used with
                   this option.  This option can be specified multiple times.
                   Use of -g implies -a if -n is not specified.

where -a is:

List installed packages and list the newest version of package that are not installed but could be installed in this image.

this wasn't super clear about what happens if a package is both installed and a newer version of that package is available, but it seems in practice the answer is "list the installed version, not a new version". in the case of a package like /system/kernel, that's already installed (surprise), carrying on through to more visible packages like consolidation/osnet/osnet-incorporation. so, it's less that Helios was pinned as much as we were very committed to whichever bits are present when a TUF is built. given that the helios / build TUF repo job runs on the helios-2.0 host this wouldn't even have been obvious up front since that's also probably relatively recent versions of everything. though before now i hadn't really wondered how a helios-2.0 comes to be...

-n as Andy suggested always shows the newest version of packages, avoiding... this. passing -af with an FMRI of *@latest might also do, but -n seems more straightforward.

the TUF built with 3a173a0 mentions [email protected], rather than yet another 23359, so that bodes well!